Method and apparatus for managing a collection of portlets in a portal server

ABSTRACT

The invention provides apparatus and methodology for displaying to a user a web portal for a web application, the web portal displaying a plurality of associated portlets, sharing information with each other, accessible by the user; including: a portal server for operating a web portal to provide access to the web application; a portlet application for operating on the portal server, for managing a collection of associated portlets; the portlet application includes: means to initiate portlets on requests of a user to access the web application; means to manage a portlet application session object for the portlets; and, a portlet application session object data store controlled by the portlet application session object for saving parameters from user requests for associating the portlets with the with the portlet application session object.

FIELD OF THE INVENTION

This invention relates to the Internet, more particularly to methods andapparatus for producing and using portals and portlets in webapplications to provide enhanced capabilities for web sites.

BACKGROUND OF THE INVENTION

The World Wide Web brought a paradigm shift to communications over theInternet, conveying graphical information to users. With the advent ofthe Web there was and still is demand for increasing communicability andbroad connectivity.

The Portal (previously known as a web portal) has brought a majorparadigm shift in internet space. A web site that offers an array ofresources or services such as email forums, search engines, databases orother information may be considered to be a portal. The first webportals may have been online services. For the first time, users surfingthe internet were able to see web pages that were assembled with andoffered information coming from various sites in the world wide web, yetthe aggregation's constitution was transparent to the user. A usermaking use of a typical web browser sees a cohesive web page displayed.The origination of different parts of the page from various internetsites not associated with the web site being viewed is not readilyapparent. These parts are termed Portlets.

Portlets are the visible active components end users see within theirportal pages. Similar to a window in a PC desktop, each portlet “owns” aportion of the browser or Personal Digital Appliance screen where itdisplays results.

From a user's view, a portlet is a content channel or application towhich a user subscribes, adds to their personal portal page, andconfigures to show personalized content.

From content providers' view, a portlet is a means to make availabletheir content.

From a portal administrator's view, a portlet is a content containerthat can be registered with the portal, so that users may subscribe toit.

From a portal's point of view, a portlet is a component rendered intoone of its pages.

From a technical point of view, a portlet is a piece of code or a smallapplication that runs on a portal server and provides content that is tobe embedded into portal pages. In the simplest terms, a portlet may be aJava™ servlet that operates inside a portal.

Each part (portlet) of a given page (typically sourced from differentplaces in the world wide web) can collaborate with another part(portlet) of the same page to achieve higher function for a user surfingor accessing the page. Thus, a portal becomes the single point of accessfor multiple users, via multiple channels, to multiple sources ofinformation.

Portals can be applied in various business models, namely: business toconsumer, business to business, or business to enterprise. The key toquick adoption of the portal paradigm ties strongly to its ability tointegrate existing web application data into the portal framework in aseamless fashion.

However, various technical hurdles still exist for such seamless webapplication integration into portal.

There are limitations in the prior art concerning how the followingportal artifacts work together with existing web applications. Theimplementation of integration of web applications into portalarchitecture is not well defined. These entities include:

-   -   Original http request to a portal;    -   A portlet session within a portal;    -   A http request from the portal to the pertinent web application.

When different users access a portal page, the original http request foreach user is directed towards the portal server (a). The original httpsession for each user is also entirely “owned” by the portal server.Each of the portlets has its own independent session called a portletsession. When a portlet needs to render information that comes from agiven web application, (b), there are typically the following technicalhurdles:

-   -   i. There is no existing mechanism for a portlet to generate http        requests and responses to and from the backend web application.    -   j. There is no existing mechanism to manage multiple requests        and responses to a calling portlet (and the portlet session)        mapping correctly with multiple requests and responses to a        backend web application (and the web application's session).        Each (both portlet and web application) maintains its user        session accordingly.

This gets complicated when multiple portlets call the same webapplication, with the web application treating these multiple portletsrequests within the same web application session.

-   -   k. There is no existing mechanism to relay session information        between the multiple portlet sessions and the web application's        session.

When a well defined set of portlets within the same portlet applicationinteract with the one web application at the backend, all theparticipating portlets must be able to retrieve and forward the correctsession information to the web application at the backend such that theinformation rendered from the web application is consistent with thesetting of that of the portal of the portlets. Examples of such settingincludes locale information, user agent of that particular access etc.For example, the responses sent from the web application must be usingthe same locale with the portlet in the portal server who displays it.

There is no existing mechanism for single sign on such that the portaluser's credentials will not be challenged by the backend webapplication. This is a critical requirement. The absence of it willresult in the user's credentials being challenged when the user movesfrom one part of a web page to a different part of the same web page; asthe portlets have different originations and identificationrequirements.

There is no existing mechanism for synchronization of multiple requestsor responses between portlets of a given portlet application and thepertinent web application backend.

The prior art has limitations concerning how multiple portlets withinthe same portlet application can collaborate with one another (sharingthe same context) as well as with the various integrated webapplications dynamically is not defined.

One Usage Scenario involving multiple portlets collaborating by sharingthe same ‘context’ dynamically will serve to conceptually illustrate thelimitation:

With three portlets being displayed on the same portal web page:

-   -   one portlet shows the account summary by displaying a list of        accounts    -   the second portlet shows a given account's list of outstanding        invoices    -   the third portlet shows a given account's order history summary

The second and the third portlets are contextually bound to the firstportlet dynamically, reflecting outstanding invoices (2^(nd) portlet)and order history (3^(rd) portlet) and are synchronized with an accountselected from the account list of the first portlet.

Limitations of the Prior Art:

-   -   i. No mechanism exists to define a sub-grouping of portlets        within a portlet application that would work collaboratively.    -   j. No mechanism exists to define a context (that can be        dynamically changed) shared among this sub-group of portlets        within a given portlet application: example of context here is        the selected account in portlet 1, such account selection can be        changed dynamically.    -   k. No mechanism exists to detect the change in context        dynamically: example of the change of selection from one account        to another account from the account list in portlet 1 of the        above example.    -   l. No mechanism exists to register a predefined action (or        responses) for each participating portlets within the sub-group        of portlets that share the same context: example of displaying        the list of outstanding invoices (action in portlet 2) when the        context is changed (from one account selection to another in        portlet 1).    -   m. No mechanism exists to relay that dynamic context to the        relevant integrated web applications

There is no mechanism existing in the prior art to define a refreshsequence for a group of portlets within a portlet application

-   -   i. There is no provision today for a portal designer to specify        the refresh order of a given set of portlets being displayed.

In our scenario above, the portal designer would want to have the firstportlet (account list) refreshed first, the second portlet refreshedsecond etc. so that the 2^(nd) and the 3^(rd) portlets automaticallyhave. Defined actions (when the portlet is deployed) taking place in acorrect sequence.

There is a lack of a well defined mechanism in portal architecture tosupport the aggregation of portlets based on business rule and userprofiling information including the users' role.

-   -   i. There is no existing mechanism to define aggregation of        portal resources per user based on business rules.        -   Example: all teenage portal users see one group of portlets,            all senior portal users see another group of portlets.    -   j. There is no existing mechanism for such rule based and user        based aggregation of portlets that is performed dynamically at        runtime.

There is no sharing of portal level business rules and user profileinformation with pertinent integrated back end web applications.

There is no sharing of business rules or user segmentation informationwith an integrated web application such that these rules and usersegmentation can be consistent across a portal and its integratedbackend web application. For example, if there is a rule defining theage range of a teenager, such a rule should be visible and applicable tothe integrated web application for consistency.

Terminology

Portlets

Portlets are the visible active components that the end users see withintheir portal web pages. Similar to a window in a PC desktop, eachportlet “owns” a portion of the browser or PDA (Personal DigitalAppliance) screen where it displays portlet specific information.

Portlet Application

Portlets can also be grouped together in a portlet application. Portletapplications are distributed and deployed using Web archive files (WAR).There are portlet specific extensions to the standard Web applicationdeployment descriptor.

Portlet Messages

Portlet messages are used for the communication between two portletsusing portlet actions and portlet messages. The sending portlet createsa portlet action, encodes the action into a URL. When the URL isaddressed, e.g. by a user trying to accomplish an task, the actionlistener is called and sends a portlet message to send the necessarydata.

Portlet Session

A Portlet session is created for each portlet instance for each userlogging on to maintain session information for each user per portletinstance.

SUMMARY OF THE INVENTION

The various embodiments of the invention herein address one or moreshortcomings of the prior art.

When users access a portal page, the original http request for each useris directed towards the portal server. Each of the portlets has its ownindependent session called a portlet session. An embodiment of theinvention provides a system for synchronization of multiple requests orresponses between portlets of a given portlet application and thepertinent web application backend and there was no existing mechanismfor portlets of a given portlet application to generate http requestsand responses to and from the backend web application in such a mannerthat the back end http session is maintained cohesively.

One aspect of the invention provides a set of methods to enable acollection of portlets within the same portlet application to initiateportlets requests to access said web application maintaining cohesivesession to the backend application; to manage a portlet applicationsession object for said portlets; to provide a common data store for theportlets within the same portlet application including saving parametersfrom user requests.

Another embodiment of the invention provides a portlet applicationcommunication client in said portlet application for communicatingbetween portlet application session object and said web application toconvey user requests. The embodiment also may also provide a common key,granting the key to each associated portlet for controlling access tothe portlet application object. This common key is also used formatching up http sessions owned by the portal server and the httpsessions owned by the backend web application. The communication clientmay have a request buffer for storing and serializing requests from theassociated portlets to enable the communication client to generateserialized to the web application.

With an embodiment of this invention, it is now possible to have acommon backend web application integration model, enabling nativeportlet integration of web application without launching separatebrowsers with a single sign on for a user. It also provides mechanismfor session management between the portlets and the web applicationbackend.

One embodiment of the invention provides apparatus for displaying to auser a web portal for a web application, the web portal displaying aplurality of associated portlets, sharing information with each other,accessible by the user; including: a portal server for operating a webportal to provide access to the web application; a portlet applicationfor operating on the portal server, for managing a collection ofassociated portlets; the portlet application includes: means to initiateportlets on requests of a user to access the web application; means tomanage a portlet application session object for the portlets; and, aportlet application session object data store controlled by the portletapplication session object for saving parameters from user requests forassociating the portlets with the with the portlet application sessionobject.

The apparatus of the invention may include a portlet applicationcommunication client in the portlet application for communicatingbetween the portlet application session object and the web applicationto convey user requests received from the associated portlets to the webapplication. The portlet application may assign a common key to eachportlet associated with a portlet application session object.

Another embodiment of the invention provides an apparatus for displayinga web portal for a web application to a plurality of users, the webportal displaying a plurality of portlets, sharing information,accessible by the users; including: a portal server for operating a webportal to provide access to the web application; a portlet applicationfor operating on the portal server for each of the plurality of users,for managing a collection of associated portlets for each of theplurality of users; each the portlet application includes: means toinitiate portlets on requests of one of the plurality of users to accessthe web application; means to manage a portlet application sessionobject for the portlets; and, a portlet application session object datastore controlled by the portlet application session object for savingparameters from user requests for associating the portlets with the withthe portlet application session object.

Another embodiment of the invention provides apparatus for displaying toa user a web portal for a plurality of web applications, the web portaldisplaying a plurality of associated portlets, sharing information witheach other, accessible by the user; including: a portal server foroperating a web portal to provide access to the web application; aplurality of portlet applications relating respectively to the pluralityof web applications for operating on the portal server, each portletapplication being adapted to managing a collection of associatedportlets; each the portlet application includes: means to initiateportlets on requests of a user to access one of the plurality of webapplication; means to manage a portlet application session object forthe portlets; and, a portlet application session object data storecontrolled by the portlet application session object for savingparameters from user requests for associating the portlets of theportlet application with the with the portlet application session objectof the portlet application session.

Another aspect of the apparatus of the invention includes a user sessioninformation table adapted to connect to multiple web applications withthe portlet application session object.

Still another embodiment of the invention provides apparatus fordisplaying to a user a web portal for a web application, the web portaldisplaying a plurality of associated portlets, sharing information witheach other, accessible by the user; including: a portal server foroperating a web portal to provide access to the web application; aportlet application for operating on the portal server, for managing acollection of associated portlets; the portlet application including:means to initiate a first portlet on request of a user to access the webapplication; means to create a portlet application session object forthe user for the first portlet; means to save parameters from therequest; means to generate additional portlets associated with the firstportlet on further requests of the user to access the web application; aportlet application session object data store controlled by the portletapplication session object for using the saved parameters forassociating the additional portlets with the with the portletapplication session object; and, means to create a portlet applicationcommunication client (httpClient) for communicating with the portletapplication session object and the web application to convey userrequests received from the first and additional portlets to the webapplication.

The apparatus may include a portlet application communication client inthe portlet application for communicating between the portletapplication session object and the web application to convey userrequests received from the associated portlets to the web application.

The portlet application preferably assigns a common key to each portletassociated with a portlet application session object.

A user session information table adapted to connect to multiple webapplications with the portlet application session object mayadvantageously be provided.

Another embodiment of the invention provides apparatus for displaying toa user a web portal for a web application, the web portal displaying aplurality of associated portlets, sharing information with each other,accessible by the user; including: a portal server operating a webportal to provide access to the web application; a portlet applicationoperating on the portal server, for managing a collection of associatedportlets; the portlet application including: means to initiate portletson requests of a user to access the web application; means to manage aportlet application session object for the portlets; and, a portletapplication session object data store controlled by the portletapplication session object for saving parameters from user requests forassociating the portlets with the with the portlet application sessionobject.

Another aspect of the invention provides a method of sharing informationbetween a plurality of associated portlets in a web portal including:granting access for each of the plurality of associated portlets to aportlet data store; permitting each of the plurality of associatedportlets to write data to the portlet data store and to read stored datafrom the portlet data store.

The method above may advantageously provide a system wherein theassociated portlets are managed by a portlet application adapted tooperate on a data processing system; wherein the portlet data storecomprises portlet application storage managed by a portlet applicationsession object which controls reading and writing of data by theassociated portlets in the data store permitting exchange of data amongthe associated portlets of the portlet application.

Another aspect of the invention provides apparatus for sharinginformation between multiple associated portlets in a web portalincluding: a portlet application for managing the multiple associatedportlets; a portlet application data store; means for grantingread/write access to the data store by the multiple associate portletsto enable the portlets to exchange data among each other.

Yet another aspect of the invention provides a portlet (application)server capable of operating on a portal server for hosting multipleassociated portlets in a web portal including: means for managing themultiple associated portlets; means for managing a portlet applicationsession object; a portlet application data store managed by the portletapplication session object for granting read/write access to the datastore to the multiple associate portlets to enable the associatedportlets to exchange data among each other.

Another aspect of the invention provides a portlet (application) servercapable of operating on a portal server for hosting multiple associatedportlets in a web portal including: means for managing the multipleassociated portlets; means for creating and managing a portletapplication session object; a portlet application data store created andmanaged by the portlet application session object for grantingread/write access to the data store to the multiple associate portletsto enable the associated portlets to exchange data among each other.

Advantageously, the portlet application assigns a common key to eachportlet associated with a portlet application session object.

Another aspect of the invention provides a portlet application capableof operating on a portal server for hosting multiple associated portletsin a web portal accessible by a user, including: portlet applicationmeans for managing the multiple associated portlets; portlet applicationmeans for managing a portlet application session object for the user;portlet application means for granting the key to each associatedportlet for controlling access to the portlet application object.

Still another aspect of the invention provides a portlet applicationcapable of operating on a portal server for hosting multiple associatedportlets in a web portal accessible by a user, including: portletapplication means for managing the multiple associated portlets; portletapplication means for creating and managing a portlet applicationsession object for the user; portlet application means for creating andmanaging a key for the user for the portlet application session object;portlet application means for granting the key to each associatedportlet for controlling access to the portlet application object.

Advantageously one portlet application is assigned to each user and onekey is assigned respectively for each user to respective portletapplication objects for each portlet application.

Another aspect of the invention provides apparatus for displaying to auser a web portal for a web application including: a portal server foroperating a web portal to provide access to the web application by auser; a portlet application, for managing a collection of associatedportlets, for operating on the portal server; a portlet applicationsession object for the user for the associated portlets; a portletapplication session object data store controlled by the portletapplication session object; a portlet application communication clientlinked to the portlet application data store for communicating betweenthe associated portlets and the web application to convey user requestsreceived from the associated portlets to the web application; thecommunication client having a request buffer for storing andsynchronizing requests from the associated portlets to enable thecommunication client to generate synchronized to the web application.

Preferably the portlet application communication client is adapted tosend information including requests over a network to a web applicationand receive information including responses to the requests from the webapplication.

Another aspect of the invention provides apparatus for displaying to auser a web portal for a web application including: a portal server foroperating a web portal to provide access to the web application by auser; a portlet application, for managing a collection of associatedportlets, for operating on the portal server; a portlet applicationsession object for the user for the associated portlets; a portletapplication session object data store controlled by the portletapplication session object; a portlet application communication clientlinked to the portlet application data store for communicating betweenthe associated portlets and the web application to convey user requestsreceived from the associated portlets to the web application; thecommunication client having a request buffer for storing and serializingrequests from the associated portlets to enable the communication clientto generate serialized to the web application.

Preferably, the portlet application communication client is adapted tosend information including requests over a network to a web applicationor web application server and receive information including responses tothe requests from the web application.

Another aspect of the invention for a portal server adapted to operate aweb portal to provide access to a web application; having a portletapplication operating on the portal server, for managing a collection ofassociated portlets; wherein the portlet application includes: means toinitiate portlets on requests of a user to access the web application;means to manage a portlet application session object for the portlets;and, a portlet application session object data store controlled by theportlet application session object for saving parameters from userrequests for associating the portlets with the with the portletapplication session object, the apparatus including: a portletapplication communication client (httpClient) linked to the portletapplication data store for communicating between the associated portletsand the web application to convey user requests received from theassociated portlets to the web application; the portlet applicationcommunication client having a user session information store (mappingtable) for storing user session information including selectedinformation from the set of the following user session information: userid, user credentials, language preferences, session timeout information,session id, etc. for mapping the user session information to acorresponding session of the web application.

The session timeout information preferably includes session timeoutinformation of the portal server and the web application.

Another aspect of the invention provides portlet application, formanaging a collection of associated portlets in a portal, for operatingon a server providing access to a web application by a user; theassociated portlets having portlet request parameter maps storing dataand instructions from user requests to the portlets; a portletapplication session object for the user for the associated portlets; aportlet application session data store controlled by the portletapplication session object; a portlet application communication client(httpClient) linked to the portlet application data store forcommunicating between the associated portlets and the web application toconvey user requests received from the associated portlets to the webapplication; the communication client having a request buffer forstoring requests from portlet request parameter maps of the associatedportlets to enable the communication client to provide data andinstructions for the web application.

Another aspect of the invention provides a portlet applicationcommunication client (httpClient) linked to the portlet application datastore for communicating between the associated portlets and the webapplication to convey user requests received from the associatedportlets to the web application; the portlet application communicationclient having a user session information store (mapping table) forstoring user session information including selected information from theset of the following user session information: user id, usercredentials, language preferences, session timeout information, sessionid, etc. for mapping the user session information to a correspondingsession of the web application; the session timeout informationincluding session timeout information of the portal server and the weapplication.

Preferably the above includes synchronization means for the portletapplication communication client for matching session timeouts betweenportal server and the web application by re-authenticating the user ifthe web application times out before the portal server.

Another aspect of the invention provides a portlet application capableof operating on a portal server for hosting multiple associated portletsin a web portal accessible by a user, the portal server providingmessaging means for allowing the associated portlets to message eachother, including: portlet application means for managing the multipleassociated portlets; each associated portlet having a portlet descriptordescribing context names; the associated portlets includingcollaboration groups of portlets having corresponding context namesdefining context values; each the group of portlets including a masterportlet and at least one slave portlet; wherein each the group ofportlets share context names in common; means in the portal server forbroadcasting communicating changes in context values of a master portletto slave portlets of the master portlet; means in the portal server forchanging context values of the slave portlets to match context values ofthe master portlet as broadcast.

Another aspect of the invention provides a portlet application capableof operating on a portal server for hosting multiple associated portletsin a web portal accessible by a user, the portal server having portletrefresh capability, including: portlet application means for managingthe multiple associated portlets; each associated portlet having aportlet descriptor; each portlet descriptor including refresh prioritydescription for the portlet; the associated portlets includingcollaboration groups of portlets; each the group of portlets including amaster portlet and at least one slave portlet; means in the portletapplication means for refreshing the portlets in order of their refreshpriorities.

Still another aspect of the invention provides a portlet applicationcapable of operating on a portal server for hosting multiple associatedportlets in a web portal accessible by a user, the portal server havingportlet refresh capability, including: the associated portlets includingcollaboration groups of portlets; portlet application means for managingthe multiple associated portlets; each associated portlet having aportlet descriptor; each portlet descriptor including a refresh prioritydescription for the portlet, and a refresh description priority for thegroup of portlets of which the portlet is a member; each the group ofportlets including a master portlet and at least one slave portlet;means in the portlet application means for refreshing the portlets inorder of their priorities; means in the portlet application means forrefreshing the collaborative groups of portlets in order of their grouprefresh priorities.

The master portlets have higher priorities than slave portlets.

Preferably the portlet application refreshes the groups first in grouppriority order and then refreshes within each group in priority order.

Another aspect of the invention provides apparatus for displaying to auser a web page session for a web application, the web page sessiondisplaying a plurality of associated collaborative portlets, sharinginformation with each other, accessible by the user including: a portalserver for operating a web portal to provide access to the webapplication; a portlet application, for managing a collection ofassociated portlets, for operating on the portal server; access means toaccess a rules database; the rules including rules controlling displayof sets of portlets, pages, page groups to users; selection means toselect a set of portlets, pages, and page groups to be displayed to auser based on information provided by the user (information properties).

In another variation of the invention the selection means includes apluggable rules engine, a rules database, and a portlet applicationaggregation engine which applies rules to select and display selectedportlets, pages, and page groups to a user.

Another aspect of the invention provides apparatus for displaying to auser a web page session for a web application, the web page sessiondisplaying a plurality of associated collaborative portlets, sharinginformation with each other, accessible by the user including: a portalserver for operating a web portal to provide access to the webapplication; a portlet application, for managing a collection ofassociated portlets, for operating on the portal server; roles accessmeans to access a roles database; the roles database containing rulescontrolling display of sets of portlets, pages, page groups to usersbased on user roles; role selection means to select a set of portlets,pages, and page groups to be displayed to a user based on an identifiedrole of the user.

Other aspects of the invention provide an article including: a computerreadable signal bearing medium; computer program code means recorded onthe medium adapted to perform the methods of the embodiments of theinvention described above.

Other aspects of the invention provide an article including: a computerreadable signal bearing medium; computer program code means recorded onthe medium adapted to implement the apparatus of any of the embodimentsof the invention described above.

The medium may be selected from the group consisting of magnetic,optical, biological, and atomic data storage media as appropriate.

The medium may be a modulated carrier signal.

The signal may be a transmission over a network.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the present invention will be described by way ofexample, referring to the accompanying drawings in which:

FIG. 1 depicts a Dynamic Context Chaining Model;

FIG. 2 depicts a Web Application Integration With Portal;

FIG. 3 depicts an integration Structural Diagram;

FIG. 4 depicts an Integration Flow Diagram;

FIG. 5 depicts a Structure Diagram for Portal integration with WebApplication;

FIG. 6 depicts a Flow Chart for Integration;

FIG. 7 depicts an Example Of Dynamic Context Groups for Portlets;

FIG. 8 depicts a Portlet Application Initialization For Dynamic ContextAs Specified In the definition instance;

FIG. 9 depicts a Dynamic. Context Portlet Group Run Time Flow;

FIG. 10 depicts a Role Based Dynamic Aggregation Component StructureMap;

FIG. 11 depicts a Rule Based Dynamic Aggregation Component Flow Map;

FIG. 12 depicts a Role Based Dynamic Aggregation Flow Chart;

FIG. 13 depicts the handling of portlets requests to web applications;

FIG. 14 depicts a sync model diagram;

FIG. 15 depicts a flow chart for a sequence aware portal aggregationengine;

FIG. 16 depicts the defining of a dynamic group called “MaleTeen” andassigning users to the group;

FIG. 17 depicts the assigning a rules database content group selectionaction to a dynamic user group; and,

FIG. 18 depicts the creation of a new action called “maleTeenAction”.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS OF THE INVENTION

This section describes preferred embodiments of the invention.

A.1. Portal and Web Applications Integration Enablment

FIG. 2 illustrates a preferred embodiment of the invention illustratingits use with a web portal server.

A.1.1 Portlet Application http client

The portlet (that makes http requests to the back end web application)uses the Portlet Application Http client 209 used to open an Httpconnection to a backend web application that runs on a backendapplication server 210. The backend web application requires a PortletApplication Http client 209 to provide session support over multiplerequests and responses, cookie handling and Single Sign on (SSO) logic.All the portlets in the same portlet application use the same portletapplication Http client object 209 to connect to one or more backend webapplications. There is one Portlet Application http client 209 perportlet application 204.

A.1.2 Portlet Application Session

The Portlet Application Session object 208 is a unified data storeobject that can be shared by all portlets in a given portletapplication. This object exists per user and per portlet application.The Portlet Application Session object 208 provides infrastructure sothat multiple portlets in a given portlet application will haveindependent user sessions (called portlet sessions 204 205,206) butshare the same Portlet Application Session, and communicate with the webapplication on the backend application server 210 with a single webapplication session.

A.1.3 Portlet Application Session Context

Portlet Application Session Context provides information that is peruser and per portlet application. This means that all portlets withinthe same portlet application (204, 203) can now have a way to sharecommon information among them.

A.1.4 Session Relay Mechanism 320

The Session relay mechanism enables the passing of information from theoriginal http session held by the portal server to the back end httpsession created by the portlet application's http client. This mechanismuses the following infrastructure:

Cookie Table 305 & Cookie Lookup Key

Cookie table 305, (a user session information table) is the main entityfor mapping the portal server cookies to the backend web applicationsession cookies. The mapping relationship between the cookie of the httprequests to the portal server and the cookie of the portlet applicationhttp client to one given web application is one to one. However, A givenportlet application http client can make http requests to different webapplications with each web application maintaining independent sessions.With that regard, the mapping between the portal server session cookieand that of the backend web applications can be one to many (due tomultiple backend web application servers).

FIG. 13 depicts this mapping, in which a number of items areillustrated:

RQ1: cookie from the http request of a user agent (browser) to theportal server

RQA: cookie from the http request of the portlet http application clientto the web application A

RQB: cookie from the http request of the portlet http application clientto the web application B

The Portlet Application Http client 209 uses this table to look up thematching cookie to the backend web application running on the backendweb application server 210.

The existence of this cookie mapping table 305 enables the automaticexpiration of a backend web application session when the portal serversession expires.

Cookie Lookup Key

The portlet application http client 209 is created per portletapplication. The cookie lookup key is stored in the portal applicationsession object which is accessible to all the portlets within the sameportlet application. This cookie lookup key is responsible for matchingthe http session of the portal server with the http session of the backend application.

The use of the cookie lookup key allows all portlets in a given portletapplication who share the same Http Client key to retrieve and forwardthe correct set of backend web application information for the currentlylogged in user such that all the portlets in the same portletapplication work in synchronization to update the backend webapplication being used. The effect is that the end user sees a unifiedview of the backend web application through multiple portlets.

Portlet Request Parameter Map

The Portlet Request Parameter Map 308 is in a memory object stored inthe shared application session data store which is created per portlet,per portal server session. It is used to store all request parametersfrom an incoming user request to a particular portlet.

A.2. Dynamic Content Synchronization of Portlets

A.2.1 Dynamic Context Definition Template

FIG. 5 illustrates portal integration with a backend web application.Reference to FIG. 5 will be useful for the following:

The Dynamic context Definition template 503 defines the following foreach Dynamic Context Group:

-   -   the context and its type (in our previous example, it is the        Account ID)    -   the master portlet who can change the value of the context        defined    -   the slave portlet(s) who get notified when the defined context        is changed    -   the slave portlet(s) registered response (or action) upon        notification of the context change    -   optionally defines the refresh sequence of the slave portlets        (master always get refreshed first within a given group)

One Dynamic Context Definition Template 503 can contain one or manyDynamic Context Group(s). But each Dynamic Context Group can only have

-   -   one master portlet    -   one defined context    -   one or more than one slave portlets        Notes: a given portlet can participate in more than one Dynamic        Context Groups with different roles in each group.        A.2.2 Dynamic Context Portlets Grouping Generation Tool

This tool 501 reads in the Dynamic Context Definition Template 503 andgenerates Dynamic Context Master Portlet and Slave Portlets for allDynamic Context groups according to the definition specified by updatingthe portlet deployment descriptors 502 correspondingly.

A.2.3 Dynamic Context Group

A dynamic context group is a subset of portlets that share the samecontext and are grouped under one dynamic context group. A given portletcan belong to more than one dynamic context group.

The Dynamic context group definition document instance 504 is used todefine the dynamic context of a particular dynamic context group).

Dynamic Context Master Portlet

Dynamic Context Master Portlet is responsible for

-   -   detecting the context state change    -   notifying all slave portlets on the context state change        Dynamic Context Slave Portlet(s)        Dynamic Context Slave portlets do the following:    -   pulling for context change as notified by the master portlet    -   performs the registered action directed towards the        corresponding back end application upon notification of context        change        Dynamic Context Models

There are two types of Dynamic Context models that can be used forassociating portlets with each other:

A.2.4 The Sync Model

In the Sync model, depicted in FIG. 14, the master portlet 101 informsthe slaves 1701-1703 about the state change of the context of theDynamic context master portlet. All slaves will perform actions based ona previously defined response to sync up with the master's context statechange.

Sync Model Diagram

A.2.5 The Chaining Model

In the chaining model, indicated in FIG. 1, the change of state inMaster A 101 results in the response action of Slave A 102, Slave A isalso the Master portlet B, which leads to the change of state in contextB, resulting in the context change response of Slave B 103, slave B isalso the master portlet of dynamic context group C, resulting in theaction response of Slave C.

A.2.6 Portlet Transaction Manager:

A Sequence Aware Portal Aggregation Engine Extension Referring to FIG.15, the portlet transaction manager 1802 is the component responsiblefor managing the runtime refresh sequencing of the portlets includingthe creation of portlet requests, responses, and sessions.

1. The first portlet to be refreshed for any portlet application isdefined as that portlet which is refreshed first among all the portletsfor a given user. There is no existing mechanism to define therefreshing sequence of portlets within a given page.

Thus, we need some logic which can identify the master portletdynamically at runtime. In the present invention we use a simplescratchboard where each portlet makes a mark every time it is refreshedthe first time a portlet makes a mark on this scratchboard it knows thatit is the first or master portlet. The next portlet that makes a mark onthis list can already see that other portlet has made a mark on it andknows that it is not the master portlet, etc. The next time the portalpage is refreshed, the first portlet that makes a double mark on thislist becomes the master portlet. The master portlet then, reinitializesthis list by removing the marks of all the other portlets and also oneof its double marks for the next request. This algorithm allows us todetect the master portlet dynamically every time a request comes in fromthe portlets' portal server.

After the first portlet is refreshed the transaction manager takes overto refresh the other portlets in the sequence as predefined in themaster and slave portlet mapping of the dynamic context group.

2. Sequence sorter: The sequence sorter module 1804 is used to sort theportlets in their refresh sequence order. It used the portlet deploymentdescriptor to identify the refresh order of each portlet and then sortsthem out for the request dispatching engine.3. Sequence Aware Request Dispatching Engine Extension: This engine 1805is used to dispatch requests to the portlets and over-rides the portalaggregation engine. Its job is to construct the appropriate portletrequest and response objects, as well as the portlet session for all theportlets in the commerce portal application. It is then used by thetransaction manager to actually refresh the portlets.4. Transaction Manager Caching Unit: The transaction manager cachingUnit 1806 is used by the transaction manager 1802 to cache the responsesproduced by the portlets as they are refreshed by the requestdispatching engine. This is necessary as when the portal aggregationengine now requests for a portlet refresh, these cached responses aresent back to it by the transaction manager. This avoids the problem ofdouble refresh per incoming portal request.A.3. Rule Based and Role Based Aggregation

FIG. 11 illustrates a rule based dynamic aggregation component structuremap of a preferred embodiment of this invention. A description of thecomponents of the illustrated embodiment and their operation follow:

Portal Resource Translation Module

The portal resource translation module 1015 is responsible fortranslating the set of Portal resources including: portlets, pages andpage groups into a form that can be parsed and processed by the externalrules engine 1022.

Rules Database

The rules database 1001 holds business manager defined rules for theportal aggregation engine 1006.

User Resource Translation Module

The user resource translation module 1013 is responsible for translatinguser resources and the various user properties into a form that can beparsed and worked upon by the external rules engine.

Pluggable Rules Engine

The rules engine 1022 is an external, pluggable rules engine (in thisembodiment of the invention), such as the Websphere™ personalizationengine, that is used for dynamic rule parsing and execution. Theengine's execution produces the set of portal resources that the usershould see based on the business rules defined by the business user andthe user properties of the current user.

Portal Roles Based Personalization Engine

The Portal roles based personalization engine 1008 is a roles basedresource selection module that is used for extracting the list of portalresources a user is allowed to access and the list of portal resourcesthe user is not allowed to access based on the user's organizationmembership.

The roles based engine 1008 first looks at the user's organization byaccessing the roles database 1007. Once the user's organization has beendetermined, his role is assumed to BE the same as the role of thatorganization. After this the roles based personalization engine 1008extracts the list of resources that have been defined as accessible andinaccessible for this organization by the business user. Once this listhas been determined IT is forwarded by this module to the portalaggregation engine's aggregated resource translation subsystem forfurther processing.

Roles DB

The Roles DB 1007 holds the organization data for the portal server. Itholds information about organization membership for various users andalso the list of portal resources that members of an organization canand can not access based on their roles.

Portal Aggregation Engine Aggregated Resource Translation Subsystem

This module 1004 is responsible for creating the master list of portalresources that the current user is allowed to see (this includesportlets, pages, and page groups) based on the output of the rules androles based personalization engines. This module is also an adapter forthe actual portal aggregation engine. Its job is to not only create thismaster list but also to translate it into a form that can then beaccessed by the actual portal aggregation engine for creating the finalweb site for the end user.

Part B: Operational Description

B.1 Portal and Web Application Integration Enabling Description

B.1.1 Overall Integration Structure & Flow Diagrams

FIGS. 2, 3, and 4, depict respectively: web application integration witha portal; an integration structural diagram; and an integration flowdiagram.

B.1.2 Detailed Deseription

Referring to FIG. 2, when a backend web application is integrated withportal server, the backend web application 221 receives requests fromthe portal server 201 via portlets. The backend web application 221sends responses back to the portlet making the request.

The response from the web application 221 is rendered via portlets ofthe portal server 201 to a user accessing the portlet.

With the implementation of the Portal Application HTTP client 209multiple requests and responses to the backend web application areperceived by the back end web application as cohesive sessions. ThePortal Application Http client 209 is used to open Http communicationconnections to the backend web application 221. The backend webapplication requires the Portal Application Http client 209 to providesession support, cookie handling and Single Sign On (SSO) capabilities.With the Portal Application HTTP client 209 in place, the portlets caneffectively communicate with web application. All the portlets in aportlet application (such as portlet application 205) need to haveaccess to one portlet application session object 211 of the back-endapplication 221, that means that Portal Application Http client 209 mustbe shared by all the portlets within the same portal application.

To make such sharing possible we have determined that a unified sessionobject that can be shared by all portlets in a given portal applicationis needed. To provide such an object the invention herein provides aPortlet Application Session object 208. The Portlet Application sessionobject 208 is an object that is created by the commerce portletapplication. The portlet application session object 208 is accessible byall portlets in a given portlet application (such as portlets 204, 205,206 in portlet application 1, 207). Without the portlet applicationsession object, 208, multiple portlets in a given portal applicationwill all have independent user sessions and will not be able to sharesession related information.

The Portlet Application Http client 209 is stored in the PortletApplication Session 208, making it possible to share it among portletsin the same portlet application. Without this portlet applicationsession object it would not be possible for the portlets to communicatewith a single web application session on the backend.

All the data that is stored in the Portal Application Session object 208represents Portal Application Session context and exists per user perportal application.

Since the Portlet Application http client 209 holds all sessioninformation for the back-end web application 221, it is used as a basefor the Session Relay mechanism 320 depicted in FIG. 3.

Session relaying allows session information to be relayed that isspecific to the whole portal server 201 (such as language information,user agent information, etc) to the session information of the back-endweb application 221. That means that the back-end web application 221 isable to deliver the data representation that conforms to all therequirements contained in the original request sent to the portal serverby a user.

For example, if the user accesses the portal using a WAP (wirelessapplication protocol) enabled mobile device, with default languagelocale set to “French” then The original http request to the portalserver 201 will have ITS language parameter set to “French” anduser-agent field of the HTTP header set to “WAP”. The Session Relaymechanism 320 relays this information to the web-application 221 and theweb application returns a response in French that is suitable fordisplay on the user's mobile device in French. If the Session Relayingwere absent the web-application would return the information in thedefault-language (for example English) suited for the default device(for example an Internet Browser). In that case the user would not beable to see the retrieved data as it would be incompatible with theuser's mobile device.

Reference will be made to elements in the structural diagram FIG. 3while process steps of FIG. 4 will be indicated by enumerate steps.

Step 401, the user interacts with portlets on a web portal, for instanceby using a computer mouse to click on a link or object displayed in aportlet on the user's web browser. Each portlet has its own portletsession 310 (portlet session is a piece of prior art). As part of theuser interaction, a remote request 306 is being made to be backend webapplication 307.

2. Step 403, in order to pass all the parameters in the portlet sessioncorrectly to the backend web application each portlet request'sparameter list is saved in the Portlet Request Parameter Map (#8) 308.These parameters are passed to the remote back end request.3. Step 404, the commerce portlet uses a http client key 301 todetermine if there is already an existing Portlet Application SessionObject 208 and Portlet Application Http Client 303 by accessing portletapplication data store #4, 302. Step 405, If one is not found, a new one30′ will be created for all the portlets within the same portletapplication. (Step 407, If one is found, the existing one will be usedinstead.)4. Step 406, each user credential from the original portlet session issaved in the cookie table 305.5. Step 408, the user credentials from the cookie table 305 and theparameters previously saved in the portlet request parameter map 308 areused to construct a new http request to the backend web application.6. Step 409, the call to remote web application is made 307.7. Step 410, the remote web application 307 returns a response to thecall for the portlet to display.B.2 Dynamic Context Synchronization of PortletsB.2.1 Development Time Description

Referring to FIG. 5 which depicts a structural diagram of portalintegration with a backend web application, it may be seen that a portaldeveloper can make use of the Dynamic Context Portlet Grouping Tool 501to create each new Dynamic Group Definition Instance 504. This instanceis a grouping of associate portlets and defines which portlets areslaves and which portlet is the master of those slaves. The requiredelements of the Dynamic Group Definition ARE specified in the DynamicContext Group Definition Template 503.

User uses the same tool 501 to update an existing Dynamic Context GroupDefinition.

After the user has provided the latest dynamic context group definition,the Dynamic Context Portlet Grouping Tool 501 updates the appropriateportlet application deployment descriptors 502 to reflect therelationships defined in the group.

Referring to FIG. 6, a flow chart representing portal integration thesteps of the above process may be more clearly visualized:

When a user wants to create (608) or update (609) a dynamic contextgroup, the user can employ the grouping tool 501 (FIG. 5).

601, the dynamic context grouping tool prompts for user input based onwhat is specified in the dynamic context group definition template 503,or in the case of updating the dynamic context grouping tool reads in anexisting dynamic context group instance, validating it with thedefinition template 503.

603, the user specifies the required information to define or update adynamic context group.

605, the dynamic context group instance 504 is generated.

606, the deployment descriptor of all related portlets are updated.

Dynamic Context Grouping

FIG. 7 illustrates dynamic context for portlets. Dynamic group 701 iscomprised of master portlet 704, slave portlet 705, and slave portlet707.

Group 703 is comprised of master portlet 705, slave portlet 706, andslave portlet 707.

Dynamic group 702 is comprised of master portlet 704 and slave portlet708.

If the data that is represented by portlets in a Portlet Application issynchronized at the back-end application level, then the portletsdeliver a coordinated view of the data just by retrieving that data fromthe web application. However, not all portlet interactions result in thechanges at the backend web application. Dynamic context serves as thesynchronization ‘at the glass’. It is most effective when a change incontext requires a different query. For example, selecting a differentaccount from the account list requires displaying of invoice informationbeing refreshed with the account selected.

In prior art systems Portlets were normally independent of each another.This invention provides method and apparatus to map the relations ofportlets with each other and articulate their dependency on each otherat portlet application deployment and configuration time. The portletsthemselves do not need to be changed.

The dependency relationships among portlets can be defined in a DynamicContext Relationship Template 503 in which the master and slaverelationships are defined.

The Dynamic Context Relationship Template 503 is preferably encoded asan XML data representation that defines the following:

-   -   the subset of portlets that constitute a dynamic context group    -   the master portlet of a dynamic context group    -   the slave(s) portlet of this dynamic context group    -   the slave action that the slave(s) have to perform upon context        state changes    -   the context that all constituents of this dynamic context group        share

An example of a Dynamic Context Group definition instance follows:

<DynamicContextGroup>  <DynamicContextGroupName>OrderRelatedPortletGroup </DynamicContextGroupName>  <DynamicContextMasterPortlet>    OrderItems </DynamicContextMasterPortlet>  <DynamicContext>itemName </DynamicContext>  <DynamicContextSlavePortlet>   <DynamicContextSlavePortletName>UPSTracking   </DynamicContextSlavePortletName>    <SlavePortletAction>     http://inventoryserver.com/inStock/    </SlavePortletAction> </DynamicContextSlavePortlet> </DynamicContextGroup><DynamicContextGroup> <DynamicContextGroupName>StockInventoryPortletGroup </DynamicContextGroupName>  <DynamicContextMasterPortlet>   InStockInventory  </DynamicContextMasterPortlet> <DynamicContext>itemSKUnumber  </DynamicContext> <DynamicContextSlavePortlet>   <DynamicContextSlavePortletName>OrderedItems   </DynamicContextSlavePortletName>    <SlavePortletAction>     http://myserver.com/lastOrdered/    </SlavePortletAction> </DynamicContextSlavePortlet> </DynamicContextGroup>

The dynamic context group Definition Instances note: one dynamic contextgroup definition is one instance. However, multiple dynamic contextgroup definitions can be consolidated into one file to define multipleinstances above defines two portlet sets in a portlet applicationconsisting of 3 portlets.

In the first dynamic context group, the dynamic context shared betweenthe portlets is itemName, the portlet named OrderedItems serves asDynamic context Master portlet and portlets UPSTracking andInStocklnventory serve as the Dynamic context Slave portlets.

In the second dynamic context group, the dynamic context shared betweenthe portlets is itemSkuNumber, the portlet named InStockInventory servesas Dynamic context Master portlet and portlet Ordereditems and serves asthe Dynamic context Slave portlets.

Each Dynamic context Master portlet observes a user HTTP request andlooks for the dynamic context. If the dynamic context is found in therequest, the dynamic context portlet sends a dynamic context (which isthe name and value pair parameter in the http request) to the Slaveportlets.

For example if OrderedItems portlet receives an HTTP request withattribute itemName set to “PentiumIV” it sends the dynamic context tothe portlets UPSTracking and InStockInventory notifying them thatcontext itemName with value “PentiumIV” was now set in the dynamiccontext.

Each Dynamic context Slave portlet listens to the master's notificationto all slave portlets of the same dynamic context group. Upon receivingthe master's notification, the corresponding slave action is invoked byadding the dynamic context to the action URL as defined in the dynamiccontext group definition instance under attribute ‘SlavePortletAction’.

For example if in StockInventory portlet receives the dynamic contextfrom OrderItems portlet with dynamic context type “itemName” and value“PentiumIV” it will retrieve the data from thehttp://inventoryserver.com/inStock/itemName=PentiumIV URL.

Coding for an example of a Dynamic Context Group Definition Templatefollows:

<xsd:schema  xmlns:xsd=“http://www.w3.org/2001/XMLSchema”  xmlns:cep=“http://www.ibm.com/WebsphereCommerceEnabledPortal/ DynamicContextGroupDefinitionSchema”>   <annotation>  <documentation xml:lang=“en”>  Schema for Websphere Commerce Enabled Portal Dynamic Context GroupDefinition   Copyright 2002 IBM Corporation  <documentation>  </annotation>   <!-Dynamic Context Group Instance -->   <xsd:elementname=“DynamicContextGroup”    type=“DynamicContextGroupDefinitionTemplate”,     minOccurs=”1”/><!-Dynamic Context Group Definition Template Schema _(—)<xsd:complexType name=“DynamicContextGroupDefinitionTemplate”>  <xsd:sequence>  <xsd:element name=“DynamicContextGroupName”type=“xsd:string”/>  <xsd:element name=”DynamicContextMasterPortlet”type=”PortletName”/>  <!- only one dynamic context per dynamic contextgroup ->  <xsd:element name=”DynamicContext” type=”ContextParameter”maxOccurs=”1”/>  <xsd:element name=”DynamicContextSlavePortlet”type=”SlavePortlet”             minOccurs=“1”/>   </xsd:sequence></xsd:complexType>  <xsd:complexType name=“SlavePortlet”>  <xsd:sequence>  <xsd:element name=“DynamicContextSlavePortlet”type=“PortletName”/>  <xsd:element name=”SlavePortletAction”type=”xsd:string”/>  <xsd:element name=”SlavePortletRefreshPriority”type=”xsd:decimal”,             minOccurs=”0”/>  <!- master's context isin the slave action url if slave param map is absent -->  <xsd:elementname=”SlaveParamMapToContext” type=”ContextParameter”            minOccurs=”0”/>   </xsd:sequence>  </xsd:complexType>  <xsd:simpleType name=“PortletName”>  <xsd:string>   </xsd:simpleType> <!- name of the parameter in master's request url -->   <xsd:simpleTypename=“ContextParameter”>  <xsd:string>   </xsd:simpleType> </xsd:schema>B.2.2 Run Time

This section will best understood by referring to FIG. 8: PortletApplication Initialization For Dynamic Context As Specified In TheDefinition Instance; and

FIG. 9: Dynamic Context Portlet Group Run Time Flow.

There are two key component to handle Runtime aspects of the DynamicContext:

1) DynamicContextActionListener (904) (Portlet Action Listener)—itlistens for the dynamic context change in the Master portlet. Masterportlet in every Dynamic Context Portlet Group hasDynamicContextActionListener attached to it.

2) DynamicContextMessageListener (906) (Portlet Message Listener)—is theMessage Listener listens for the notification from the Master of thegroup where specific Dynamic Context is defined. Every Slave portlet inthe Dynamic Context Portlets Group has a DynamicContextMessageListenerattached to it.

Step-by-step Description of the Run-Time Flow:

At portlet initialization time (FIG. 8: 801), all master portlets willadd the defined dynamic context based on the portlet descriptor (802,805) to the master portlet's action listener (806). For all slaveportlets; the dynamic context type; the action url; the parametermapping and the refresh sequence, will be retrieved from the portletdescriptor (802, 809) and add to the slave's portlet message listener(810).

1) The user interaction with the Dynamic Context Portlet Group Masterportlet results in the change of the Dynamic Context (901).

2) Master's Portlet DynamicContextActionListener detects the user'saction (902).

3) DynamicContextActionListener sets the name/value pair correspondingto the Dynamic Context in the requests object of the Master Portlet(904).

4) Master Portlet gets the value of the Dynamic Context and notifies allthe slave portlets within the same dynamic portlet group about it (905).

5) DynamicContextMessageListener associated with the Slave portlet forthe given Master receives the notification (the value of the dynamiccontext) (906).

6) DynamicContextMessageListener sets the value of the DynamicContext inthe portlet request object of the Slave portlet. (907).

7) The Slave portlet gets the value of the dynamic context (1008).

8) The Slave Portlet modifies action defined for the given Slave Portletif the mapping between context and some parameter was specified (1009).

9) If the mapping was not specified, the name/value pair of the dynamiccontext is added to the Slave's Portlet action.

10) Slave Portlet performs the Action as defined in the dynamic contextgroup instance definition (1011, 1012).

B.3 Rule Based Role Based Dynamic Aggregation

A number of figures will be referred to in this section including: FIG.10: Role Based Dynamic Aggregation Component Structure Map; FIG. 11:Rule Based Dynamic Aggregation Component Structure Map; and, FIG. 12:Rule Based Dynamic Aggregation Flow Chart.

The role and rules based dynamic aggregation components for the portletserver are based around the rules and roles databases and the concept ofcontent groups for each role and rule.

The content groups for the rules are kept in the Rules DB component 1001shown in FIG. 10. Similarly the roles content groups are defined in theRoles DB component 1007 shown in FIG. 10. Each content group consists ofa set of portal server resources that a user who has been evaluated tofall under the purview of that particular role or rule should haveaccess to.

Another major component in this scheme is the Pluggable Rules Engine1022. The task of this engine is to read in the translated userproperties and decide dynamically at runtime the set of users whoqualify for membership of a certain predefined user group based on theseuser properties. Also this engine maps the set of these dynamic usergroups to the set of content groups that have been defined in the rolesand rules DB. Preferably the Pluggable Rules Engine has a GUI to managethese tasks. The screen shot depicted in FIG. 16 illustrates how we usethe WebSphere Personalization Server Engine to manage these tasks.

For example, FIG. 16 illustrates how we define a dynamic group called“MaleTeen” and assigns all male users of ages between 16-19 to thisgroup.

As shown in FIG. 17, which depicts all users who are dynamicallyevaluated to be male teenagers based on their properties will now havethe “maleteenaction” command executed for them which would instruct thedynamic rules and roles based portal aggregation engine 1022 to selectcontent resource for the male teen group from the Roles DB 1007.

At development time it is the task of a business manager to assign a setof portal resources such as: pages, portlets etc. to a specific contentgroup in the Roles and Rules DB. This is currently done by using SQLscripts that directly load the Rules and Roles DB.

B.3. Rule Based Role Based Dynamic Aggregation Run Time EnablingDescription

At runtime the first command to execute for a portal user is the wrappercommand for the rules based engine. This command is actually a proxythat starts the evaluation of user's properties by the actual pluggablerules engine.

In the next step the rules engine reads in the user's properties fromhis stored profile, by utilizing the user resource translation module totranslate them into a form that can be understood by it.

FIG. 18 illustrates the creation of a new action called “MaleTeenAction”which selects all the portal resources that have been defined in thecontent group called “maleteengrp” in the rules DB.

FIG. 17 illustrates creation of a dynamic aggregation module commandinstructing the aggregation module to select the contents of the“maleteengrp” for all the users who fall under the purview of thepreviously created rule for classifying “MaleTeens” based on dynamicuser properties.

FIG. 17 illustrates how a given business rule (e.g. business rule indefining what constitutes a maleteen group) takes effect (e.g.maleTeenAction) in determining what content to aggregate for a givenuser, with a certain user properties, falls under such classification.

After reading in the user properties the pluggable rules engineevaluates the dynamic group membership of this user based on the rulesdefined for the various dynamic groups as shown in FIG. 18.

Once the set of dynamic groups for this user has been ascertained therules engine selects the appropriate portal content for this user byexecuting the content select ion actions defined for this dynamic groupas shown in FIG. 18. These actions upon execution return the set ofportal resources from the content groups defined for them in the RulesDB.

The next execution step is the evaluation of the roles assigned to thisuser by the roles engine. The roles engine uses the organizationmembership (extracted from the user profile properties) to extract theset of content resources for this user's role from the Roles DB. Theseresources are then added to the already existing list of rules basedportal resources created in the previous set.

This list is then forwarded to the dynamic Portal Aggregation Engine forexecution. The dynamic portal aggregation engine then selects the portalresources identified by this list to set up the default portal view forthis current user.

Summary

1. Common Backend Web Application Integration Implementation

With the Portlet Application Http Client and Portlet ApplicationSession, it is now possible to have a common backend web applicationintegration model. This can be used to enable multiple portlets withinthe same portlet application to communicate with the same webapplication backend.

This implementation of the invention makes it possible to:

i. have native portlet integration without launching separate browsers,and without requiring multiple prompts for user id and password toaccess the same backend web application;

ii. make multiple requests and receive responses to/from the backendapplication with session management.

2. Simple Common System Leading to Simple Tooling

The instant invention, provides an easy and quick method to integrateportlet applications with an existing web application operating on abackend server; with merely requiring the specification of the url ofthe pertinent backend web application in the deployment descriptor ofthe portlet application. With this, it is now possible to build toolingto take care of the commonality tasks of the integration.

3. Portlets Within the Portlet Application Share Common Session andSession Data

The implementation of a portlet application session object makes itpossible for portlets of the same portlet application to share commondata among themselves that are unique within a portlet application,while at the same time being different from that of the original httpsession of the portal server. This facilitates the sharing of dataunique among the portlets within the same portlet application.

4. Portal Session and Back End Session Sharing Common Session Data

The session relay implementation makes possible the sharing of commonsession data between a portal server and its backend web application.This enables the backend web application to receive information from theportal server, enabling business logic of the web application to exploitthis information passed from the portal server.

For example: if the current portlet state is to display the maximizedview of the portlet, the backend web application can receive this pieceof information and take advantage of this by sending back detailedbusiness information, in contrast to the normal view of a portlet, inwhich case the backend web application would just send a summary versionof the information.

5. Cohesive Back End Web Application Session Distinct From The PortalServer with the portlet application session, portlet application sessionobject, portlet http client, and the session relay mechanism A back endweb application can now preserve its own session distinct from that ofthe portal server, but still share the same cookie with that of theportal server. The backend web application can now operate independentlyand correctly, perceiving portlet requests from various portlets in aportal as one virtual client, enabling a cohesive session with thebackend web application.6. Single Sign on Across Portal Server and Back End Web Application

The session relay embodiment provides single sign-on capability suchthat the user, once logged on to a portal server, is not required toresubmit user credentials to log on to the pertinent back end webapplication. This is enabled by means of a cookie table with one to onemapping between the http session to the portal and the http session fromthe portlet http client to the backend web application.

7. Back End Web Application Behavior Synchronized with that of thePortal Server

The session relay embodiment enables enabling seamless integration bysynchronizing the behavior of a backend web application by relaying thesession information from the portal session to the session of the backend web application.

The following are some examples:

The language and locale setting in a portal server can now be passed toits backend web application so that the backend application can nowcompose a response message based on the locale+language setting of theportal server.

Another example is that session expiry information from the portalserver can now be passed to the backend web application session so thatthe backend web application session can now be timed out at the sametime that the portal session times out. The backend web application cannow be responsive to the portal state and events as relayed from theportal server.

8. Synchronized Content within the Same Portal Page

Dynamic Context Portlet Grouping allows collaboration among portletswithin the same dynamic context group to achieve business process andinformation integration and synchronization.

Each portlet is allowed to participate in multiple Dynamic ContextGroups. This provides a very open and simple programming model forportal administrator to group portlets into dynamic context portletgroups.

The simple structure of Dynamic Context definition enables simpletooling to be built for automatic generation of Dynamic Context Masterand Slave portlets for each grouping.

Dynamic Context Definition implementation, Dynamic Context Group, masterportlet and slave portlet implementation (including the slave tasks,slave context map) assist in providing advantages of the invention.

9. Ability to Define Refresh Sequence of Portlets

The transaction manager provides the capability of defining a refreshsequence of portlets for the first time. The ability to define refreshsequence of portlets enables proper implementation of sequentialbusiness logic using the portal/portlet architecture. The transactionmanager; resource sorter; the caching of responses assist in providingadvantages of the invention.

10. Rule Based and Role Based Aggregation

Fine level portal personalization can only be achieved at present bydynamic aggregation. This is distinctly different from the prior artimplementation of regular web applications in which there is no formalconcept of portlets, pages or page groups applied in accordance with theinstant invention. Fine level personalization will become more and moreimportant as the portal market takes off and user requirements for finelevel campaign targeting etc. come in.

The embodiments of the invention provide a number of advantages whichare listed below:

1. The level of personalization that can be achieved by our approach ismuch finer grained than. Portlet administration facilities provided byportal server today. The portlet administration facilities availabletoday is by nature manual configuration. Once configured, it is staticand does not change at run time. The invention here provides a dynamiccapabilities to render portal resources based on rule.2. Since the portal aggregation module is a dynamic entity, tying ofrules and roles engines directly to it lets us achieve real-time dynamicaggregation capabilities without any human intervention.3. Personalization of coarse grained portal resources such as pages andpage groups lets us perform dynamic layout.4. Much more effective campaigns, contracts etc. can be set up. This isof significant importance to both e-Commerce retail and B2Borganizations.5. the invention allows a much higher degree of personalization thanregular content personalization. For example, we can actually disableentire sections of a webpage based on rules. This can't be done byregular personalization. Further, dynamic aggregation doesn't apply tothe domain of regular personalization which is content, not resourcerelated.

1. An apparatus comprising: a portal server for operating a web portalto provide access to a web application, wherein the portal servercomprises a hardware storage device; and a portlet application foroperating on said portal server, for managing a collection of associatedportlets, wherein the portlet application is stored on the hardwarestorage device; said portlet application configured to: initiateportlets on requests of a user to access said web application; manage aportlet application session object for said portlets, wherein theportlet application session object comprises a data store object sharedby a plurality of the portlets in the portlet application, wherein thedata store is controlled by said portlet application session object forsaving parameters from user requests for associating said portlets withsaid portlet application session object, wherein the control allows forexchange of data among the associated portlets of the portletapplication; and assign a common key to each of the portlets associatedwith said portlet application session object, wherein the common key isfor controlling the associated portlets' access to the portletapplication session object, wherein the common key is further formatching http sessions owned by the portal server with further httpsessions owned by the web application; said portlet applicationcomprising a portlet application communication client for communicatingbetween said portlet application session object and said web applicationto convey requests received at the portlet application session objectfrom said associated portlets to said web application, wherein theportlet application communication client comprises: a request buffer forstoring and serializing the requests from the associated portlets toenable the portlet application communication client to generateserialized requests relative to the web application.
 2. The apparatus ofclaim 1, further comprising a user session information table configuredto connect to multiple web applications with said portlet applicationsession object.
 3. The apparatus of claim 1, wherein the portletapplication session object provides an infrastructure for a plurality ofthe portlets in the portlet application to have independent usersessions, to share the same portlet application session, and tocommunicate with the web application via a single web applicationsession.
 4. The apparatus of claim 1, wherein said portlet applicationis further configured to grant read/write access to said data store bysaid plurality of portlets.
 5. A method for use with multiple associatedportlets in a web portal, the method comprising: managing said multipleassociated portlets using a portlet application session object, whereinthe portlet application session object comprises a portlet applicationdata store object shared by a plurality of the portlets in a portletapplication, wherein the portlet application is stored on a hardwarestorage device; granting read/write access to said portlet applicationdata store by said multiple associated portlets to enable said multipleassociated portlets to exchange data among each other; assigning acommon key to each of the multiple associated portlets managed by theportlet application session object, wherein the common key is forcontrolling the associated portlets' access to the portlet applicationsession object, wherein the common key is further for matching httpsessions owned by the web portal with further http sessions owned by aweb application; storing and serializing requests received from theassociated portlets; generating serialized requests relative to the webapplication in response to the serializing of the requests; andcommunicating between said portlet application session object and theweb application to convey the serialized requests to said webapplication.
 6. The method of claim 5, wherein managing said multipleassociated portlets is implemented by a portlet application.
 7. Themethod of claim 5, further comprising managing the portlet applicationsession object, wherein the portlet application session object isconfigured to manage the portlet application data store.
 8. The methodof claim 7, wherein granting read/write access to the portletapplication data store is implemented by the portlet application sessionobject.
 9. The method of claim 7, further comprising operating a portletserver on a portal server for hosting the multiple associated portletsin the web portal accessible to a user.
 10. The method of claim 7,further comprising creating the portlet application session object forthe user.
 11. The method of claim 10, further comprising: creating andmanaging the common key for the user for the portlet application sessionobject; and granting the common key to each associated portlet.
 12. Themethod of claim 11, further comprising operating a portlet applicationon a portal server for hosting the multiple associated portlets in a webportal accessible by the user.
 13. The method of claim 12, wherein oneportlet application is assigned to each user, and one key is assignedrespectively for each user to respective portlet application sessionobjects for each portlet application.
 14. The method of claim 5, whereinthe portlet application session object provides an infrastructure for aplurality of the portlets in the portlet application to have independentuser sessions, to share a same portlet application session, and tocommunicate with the web application via a single web applicationsession.
 15. An apparatus for displaying to a user a web portal for aweb application, the apparatus comprising: a portal server for operatingthe web portal to provide access to the web application by the user,wherein the portal server comprises a hardware storage device; a portletapplication, for managing a collection of associated portlets, foroperating on the portal server, wherein the portlet application isstored on the hardware storage device; a portlet application sessionobject for the user for the associated portlets, wherein the portletapplication is further for assigning a common key to each of theassociated portlets, wherein the common key is for controlling theassociated portlets' access to the portlet application session object,wherein the common key is further for matching http sessions owned bythe portal server with further http sessions owned by the webapplication; a portlet application session object data store controlledby the portlet application session object, wherein the data store isshared by a plurality of the portlets in the portlet application,wherein the control allows for exchange of data among the associatedportlets of the portlet application; and a portlet applicationcommunication client linked to the portlet application session objectdata store for communicating between the portlet application sessionobject and the web application to convey requests received at theportlet application session object from the associated portlets to theweb application, wherein the portlet application communication clientcomprises: a request buffer for storing and serializing the requestsfrom the associated portlets to enable the portlet applicationcommunication client to generate serialized requests relative to the webapplication.
 16. The apparatus of claim 15, wherein the portletapplication communication client is further configured to generate therequests synchronized to the web application, to send informationincluding the requests over a network to the web application, and toreceive information including responses to the requests from the webapplication.
 17. The apparatus of claim 15, wherein the portletapplication communication client is further configured to generate theserialized requests to the web application, to send informationincluding the requests over a network to the web application, and toreceive information including responses to the requests from the webapplication.
 18. The apparatus of claim 15, wherein the portletapplication communication client is further configured to generate theserialized requests to the web application, to send informationincluding the requests over a network to the web application server, andto receive information including responses to the requests from the webapplication server.
 19. The apparatus of claim 15, wherein the portletapplication session object provides an infrastructure for a plurality ofthe portlets in the portlet application to have independent usersessions, to share the same portlet application session, and tocommunicate with the web application via a single web applicationsession.
 20. A computer program product for use with multiple associatedportlets in a web portal, the computer program product comprising: anon-transitory computer readable storage medium to electronically storeinstructions, wherein the instructions, when executed by a processorwithin a computer, cause the processor to perform operations, theoperations comprising: managing said multiple associated portlets usinga portlet application session object, wherein the portlet applicationsession object comprises a portlet application data store object sharedby a plurality of the portlets in a portlet application, wherein theportlet application is stored on a hardware storage device; grantingread/write access to said portlet application data store by saidmultiple associated portlets to enable said multiple associated portletsto exchange data among each other; assigning a common key to each of themultiple associated portlets managed by the portlet application sessionobject, wherein the common key is for controlling the associatedportlets' access to the portlet application session object, wherein thecommon key is further for matching http sessions owned by the web portalwith further http sessions owned by a web application; storing andserializing requests received from the associated portlets; generatingserialized requests relative to the web application in response to theserializing of the requests; and communicating between said portletapplication session object and the web application to convey theserialized requests to said web application.
 21. The computer programproduct of claim 20, wherein managing said multiple associated portletsis implemented by a portlet application.
 22. The computer programproduct of claim 20, the operations further comprising managing theportlet application session object, wherein the portlet applicationsession object is configured to manage the portlet application datastore.
 23. The computer program product of claim 22, wherein grantingread/write access to the portlet application data store is implementedby the portlet application session object.
 24. The computer programproduct of claim 22, the operations further comprising operating aportlet server on a portal server for hosting the multiple associatedportlets in the web portal accessible to a user.
 25. The computerprogram product of claim 22, the operations further comprising creatingthe portlet application session object for the user.
 26. The computerprogram product of claim 25, the operations further comprising: creatingand managing the common key for the user for the portlet applicationsession object; and granting the common key to each associated portlet.27. The computer program product of claim 26, the operations furthercomprising operating a portlet application on a portal server forhosting the multiple associated portlets in a web portal accessible bythe user.
 28. The computer program product of claim 27, wherein oneportlet application is assigned to each user, and one key is assignedrespectively for each user to respective portlet application sessionobjects for each portlet application.
 29. The computer program productof claim 20, wherein the portlet application session object provides aninfrastructure for a plurality of the portlets in the portletapplication to have independent user sessions, to share a same portletapplication session, and to communicate with the web application via asingle web application session.